currently we have 3 failing tests on the pixel5 (android 13):

• dom/media/test/test_hls_player_independency.html | Test timed out.
• dom/media/test/test_playback_hls.html | Test timed out!
• dom/media/webrtc/tests/mochitests/test_peerConnection_disabledVideoPreNegotiation.html | Test timed out.

thanks to :kinetic for pointing out in bug 1518229 there is a flag in the manifest for allowing clear text, that is required from android 9+. We currently do not run HLS tests (or media tests) on anything >android 8.0. Testing out adding this to the test_runner app

it appears the hls tests are fixed with the tip from comment 1:
https://treeherder.mozilla.org/jobs?repo=try&tier=1%2C2%2C3&revision=79064582d948308bafc5f244c38da566bf4dc7a7

the one remaining test test_peerConnection_disabledVideoPreNegotiation.html could use some attention. :pehrsons, would you be someone familiar with this test (you did the last edit), or could you put me in touch with someone who knows about it?

Sure, I wrote that test originally too. Do you have something from try I could look at?

Ok, I got the logs from the #Media chat.

So the test expects the remote video element to be black but apparently it isn't. Would it be possible to get a screenshot on test failure on this platform? That would give us a visual of what's going on.

We know from the log the video element is in readyState HAVE_ENOUGH_DATA, so it has shown a frame. We know this isn't bug 1526207 because the test disabled hw decoders (and if it was that, we should have seen an exception instead). I think we need to know what the video element is showing if want to progress this further. If a screenshot isn't feasible then we could always log a dataurl of a canvas which we drew the video element into.

thanks :pehrsons, I have a toDataURI printed out here:
https://treeherder.mozilla.org/jobs?repo=try&tier=1%2C2%2C3&revision=c241c0c446f0b8b0757b9cc0c4a63f900192232e

you have to copy the data:... from the log file, not the treeherder failures view.

Hi :pehrsons, I have some info ^^ that might help. let me know if I can get more info for you!

https://hg.mozilla.org/mozilla-central/rev/2521d014b404

Interesting. So on the left should be the local (send-side) video element and on the right the remote (receive-side) video element.

So we create the black frame here. Black in YUV is (0, 128, 128). This image is YUV420 formatted, which means that first comes the Y plane with 1 byte per pixel, then the U plane with 1 byte per 4 pixels, then the V plane with 1 byte per 4 pixels.

The image should be 640x480 pixels.

The dark green in the screenshot is RGB(0, 135, 0) aka YUV(0, 0, 0). The bright green RGB(0, 255, 0) corresponds to YUV(128, 0, 0).

The encoder seems to read zeros in the Y plane, but only for .. some 60%(?) of the image. Then it hits bytes of 128 for another 30% or so, then again zeros for the rest.

It's as if the encoder expects a stride of 1024. Then it would run out of Y plane after exactly 300 (out of 480) rows of pixels. Assuming it gets a packed buffer, the U and V planes follow immediately (with bytes of 128) and with a 1024 stride they are interpreted as 150 rows of Y plane. At this point there is no more input buffer so the encoder seems to fill out the rest (30 rows of Y, all of U and V) with zeros, or perhaps they remain from initialization.

This all doesn't seem too unreasonable, and if true we are looking at bug 1789846 which just landed. Could you run this test again on latest m-c?

perfect, bug 1789846 fixed the problem- thanks so much for your help on this.